Conferencing through various forms of media has rapidly evolved in the last few decades, particularly due to the introduction of low-cost, high-capacity communications networks.
Video conferencing and videophone calling, in particular, have made significant strides due in part to the development of tablet computers and smart phones, but also globalization of the market. With increasing travel costs, businesses and organizations have turned to conferencing to save on expenditures and/or increase contact. Interpreted broadly, a conference may be viewed as a construct for organizing related interpersonal communications over a communications network.
Generally, in these networked settings, such as over the Internet or local area networks, conferences take place between multiple parties or users using audio and/or video and/or feeds. In a conventional system, users may be invited to, or join a conference via the user's identifier (or alias thereof). An organizer of the conference may invite other users, who may be viewed as “participants” in a conference. A participant may have a persistent identity that is authenticated, or, optionally, may be permitted to join the conference without software authentication of his identity. In either case, participants may be assigned privileges and are authorized to effect various changes to the state associated with the conference. Conferences may be either non-authenticated, or include at least one authenticated participant.
In a purely non-authenticated conference, each user participant may join the conference based on the conference identifier (or alias thereof), without a user identity being checked by a server. Each user may receive an alphanumeric pass-code that determines the role of the participant within the conference session, and each role is authorized with a set of privileges to effect changes to the conference. Pass-codes may be unique to a user or shared by multiple users. User participants with a conference identifier or pass-code may join a conference through self-identification. For example, non-authenticated participants may be initially placed on hold in a conference lobby until their identity can be verified by ad-hoc means by the other participants. Optionally, non-authenticated participants may be admitted directly to the conference session, leaving it up to authorized participants to notice the non-authenticated participant, and decide whether that participant is a welcome guest versus an undesired intruder who should be ejected from the conference session.
In an authenticated conference, on the other hand, a user identity may be checked by a server. Many of today's authenticated conferencing systems are consumer-to-consumer oriented and use a flat namespace, meaning that user identities are peers to one another. In these circumstances, there is no way to determine strictly from the identity whether any two users are members of the same organization, such as a business entity, civic association, or family for example. For example, in a typical Customer Relationship Management (CRM) system, a consumer who initiates contact with the business is connected to the next available representative. Both the consumer and call representative spend time authenticating the consumer and locating the account. Beyond the consumer possibly selecting the appropriate department through voice menu prompts, neither the consumer nor the target organization has any influence on routing the consumer to the best representative for them.
In an authenticated conference, as shown with reference to FIG. 1, a known system for conferencing over a network is shown generally at reference numeral 100. In said system 100, user agents 102 and 108 (herein referred to as “UAs”) are coupled to a conferencing server 104.
In step S-1, the user agent contacts the conferencing server 104 to sign in, as well as periodically update presence information. In step S-2, the user agent 102 creates a new conference session or joins an existing one. Additional invited users that received the appropriate pass-code/credentials may similarly have their UAs join the conference session.
In step S-3, a UA 102 signals the conferencing server 104 to contact a user by name. In this circumstance, the conferencing server 104 checks the presence information for the invited user to locate a previously signed-in UA for that invited user. The conference session is terminated by a user authorized to do so, or when the last such authorized the user departs the conference session. If a suitable UA is located, the conferencing server 104 contacts the UA in order to have that UA 108 join the session. If no suitable UA is located or the invited user declines to join, the invite request in S-3 is terminated with appropriate message back to the initiating UA 102.
The above-described system has many shortcomings for an individual contacting an organization, including but not limited to: The initiating user must explicitly invite each desired user in the target organization one at a time; the initiating user must either check for presence of their specific target and/or wait to see if an invite is successful; the target organization does not automatically maintain history including past contacts; the target organization has no ability to influence the routing based on history of that user's contact with the target organization as well as that user's own preferences; and the target organization does have insight into the general reputation of the initiating user based on his past contacts with similar organizations.
As such, these known systems are not suitable for organizing the proper hierarchies and constructs on an organization level, particularly with relation to business-to-consumer and business-to-business interactions. Presently, no suitable system and method for invitation routing for conference sessions exists.